【CDI】Informatica Cloud Data IntegrationのパフォーマンスをUPさせよう！推奨設定を4つご紹介

渡部晃季

2023.11.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、データアナリティクス事業本部ビジネスソリューション部SAチームの渡部です。

InformaticaのCloud Data Integration(以降、CDI)のマッピングで、こんな悩みにぶちあたったことはありませんか？

処理時間が長すぎる
キャッシュファイルが大量に生成されてサーバーのストレージを使い切って停止してしまう
ベストプラクティスは知っているけど、なぜこの設定をしているのかわからない

もし上記のお悩みが一つでもあてはまれば、本記事が参考になるかもしれません。
今回はCDIの推奨設定について、実践的なものを4つピックアップしてご紹介いたします。

ご紹介する設定4選

JoinerにおけるDetailとMaster
Sorted Input
SQL ELT Optimization
使用しないフィールドの削除

設定の解説

JoinerにおけるDetailとMaster

まずは1つ目。
JoinerトランスフォーメーションにおけるDetailとMasterの繋ぎ方についてです。
よく考えずに上流（ソース側）から繋げている方もいるかと思うのですが、こちらの繋ぎ方でパフォーマンスが変わります。

その理由は、Masterに繋げた側のレコードがキャッシュとして作成され、キャッシュベースでDetail側のレコードと比較するからです。
Joinerトランスフォーメーションの動きとしては、Master側の全レコードがキャッシュされ、キャッシュレコードのキーをベースにDetail側のレコードと比較する、というものです。
したがってMaster側のレコードで結合キーの一意な数が少なければ、その分比較数も減り処理時間が減るというわけです。

またキャッシュが作成されすぎてしまう場合にも、上記のDetailとMasterのリンクを確認してみてください。

結論、以下になります。

結合したいテーブルのレコード数を見て、少ない方をMaster側、多い方をDetail側にリンクする

なおCDIの前身のPowerCenterでは、未ソートとソート済みのレコード同士の結合でのDetail側とMaster側の繋ぎ方について、より詳細な情報が公式ドキュメントに記載があります。
CDIもPowerCenterと同様の動きなのかはCDIの公式ドキュメントに記載がないため紹介しませんが、ご参考にして頂けたらと思います。

Sorted Input

次に2つ目。
JoinerやAggregater、Lookupで設定ができるSorted Inputについてです。

結合キーや集約キーがソート済みである場合に設定する設定で、大規模なデータセットの際に設定するとパフォーマンスが向上します。

その理由は結合にしろ、集約にしろ、ソートされていないと全行比較をしてしまうからです。
例えば集約であれば、集約キーが未ソートであれば全行スキャンするまで集約計算することができません。
最終行を見るまで集約グループが揃っているかわからないからです。
対してソート済みであれば、集約キーが変わったところで集約計算を実施できるのでスキャン量が変わります。
結果として処理時間が削減されるということです。

注意点としてはSorted Inputを設定するのに事前にソートが必要になるのですが、処理行数が少ないとソートトランスフォーメーションを配置する方が処理が遅くなってしまう場合があることです。
そのためソーストランスフォーメーションでソートを行ったり、Sorted InputのオンオフでIFの想定処理行数を用いた処理時間比較を実施するとよいでしょう。
外部環境でも変わるので明確には言えませんが、数十万行ほどであれば使用を考えるといいかと思います。

結論、以下になります。

大規模データセットの場合は、Sorted Inputを使用する

SQL ELT Optimization

折り返しの3つ目。
データベースに処理を任せるSQL ELT Optimizationです。
聞き慣れない名前かもしれませんが、2023年の11月にPushdown Optimizationから名称変更されました。
マッピングタスクで設定することができます。

こちらの設定は上記で記載の通り、ETL処理をSecureAgentに処理をさせる代わりにデータベースに処理をさせる設定です。
ネットワークトラフィックの軽減や、データベースで演算をさせることで処理の高速化が望めます。
複雑な処理や設定の場合はどうしても自動的に生成されるSQLが長くなってしまい、逆に遅くなってしまう場合もありますが、大抵の場合は処理が高速化するのでおすすめです。

注意点としてはSQL ELT Optimizationを使用した場合は、CDIの時間でのIPU消費ではなくなり、書き込み件数によるIPU消費となります。
書き込み件数が多すぎると、CDIの方がIPUコスト最適かもしれませんし、逆に書き込み件数が0件だとIPU消費が発生しないように書き込み件数が少ない場合はELTがコスト最適です。
私はこれまではSQL ELT Optimizationを使用する場合は、CDI + ELT分の料金がかかると思っていたのですが、インフォマティカ社の方から上記ご共有いただき、感動しました（笑）。
具体的なIPU消費量については、こちらをご覧ください。

IPUとはInformaticaで処理をさせた分消費する事前購入のプリペイド単位のことです。
コスト最適において、時間での消費がいい場合と、件数での消費がいい場合があると思いますが、結論は以下となります。